Server-to-Server peering occurs on TCP port 5005, and is accessible only via the ::1 (loopback) interface. This means that, in order to create a server-to-server peering, the connection must be tunneled over ssh first. Since this is an unattended server process, this requires the use of public/private key pairs to establish trust between servers.
The server-to-server stream uses JSON packets packaged into a simple ANSI-control-characters-based streaming protocol.
Sign-in occurs as follows . . . WRITEME
WRITEME
There have been 3 systems for character movement.
The oldest dates back to Tootsville I and was the d method. This is no longer in use. For documentation, to the extent any exists, refer to Tootsville IV docs. In brief, it allowed a Toot to do basically the same thing as the wtl method, only it compacted the description into a string joined with
~characters.
The current status quō method is the “d₂” method, or ``walk the line'' (wtl) method. The basic concept is that each Toot's position is determined by a linear interpolation along a straight line described by a start and end position, a speed of movement, and a start time. Thus, all clients should be able to reliably place a character at the same point on the line, regardless of any lag in the transmission. See TOOTSVILLE INFINITY-WTL- for a discussion of this method.
A more complex system being designed for post-5.0 use is the “d₃” method, which allows the client to perform pathfinding and create a Bezier spline walk pattern. This system is loosely supported by the server but in non-specific ways.
Speech mostly consists of public messages. Each public message contains a volume level, speech contents, and musical key (for the Toot sounds). TOOTSVILLE INFINITY-SPEAK handles the bulk of speech.
Private messaging is accomplished by whispering to another player using @ messages — i.e. the message begins with @ and the other player's name, and is processed by the server as a special whisper command.
Operator (Builder Toot) commands begin with a # and are processed by the server. See Appendix 7 for an index of operator commands.
Client-side commands begin with a ~ and are processed by the client, without ever sending them to the server.
WRITEME
See TOOTSVILLE INFINITY-START-EVENT and @ref{TOOTSVILLE INFINITY-END-EVENT} for an overview.
WRITEME
Clothing, Tools, and Equipment are “just” items which happen to be able to be held in a player's inventory. This is largely a function of the weight assigned and the carrying capacity of the character.
These items feature a Wear Slot value. A Wear Slot indicates a point on an avatar at which a fiece of clothing can be mounted, or an item can be held. These slots are distinct to an avatar type, so UltraToot has different Wear Slots than, say, Jack or Welduh.
Wear Slots have valences that allow multiple layers of clothing to occupy the same essential slot: eg, a T-shirt under a blazer. Some articles of clothing may be defined to block other slots or other valences; eg a full-length dress might block a shirt or pants both.
Items have energy, which can be measured in a continuous or discrete way. Continuous energy types are effectively a continuum of rational values, and energy can be expended in any fraction of that amount. Discrete energy types are an integer counter, and a specefic count is displayed to the user. When an item's energy reaches zero, it can vanish, or just remain in inventory awaiting a recharge.
Equipment and tools have special hooks to enable them to be “used” in the game world. First, they must be held in the player's trunk (for avatars with hands, they can be in the left or right hand). Second, there must be a “power” associated with the item, which requires a client-side function specialized on the item's template ID. This hook may be a simple wrapper around reporting back to the server, or it can be as ornate as necessary.
WRITEME
The metronome system allows tasks to occur on a recurring basis without having to keep their own timing threads open all the time. It also provides for one-shot events to run at a specific future time.
The main point of entry for scheduling a Metronome task is DO-METRONOME. The metronome thread itself relies upon RUN-METRONOME-TASKS to actually start tasks on each cycle.
Programmers are strongly encouraged to schedule tasks using Metronome throughout the game code.
WRITEME
WRITEME
The front-end services of Tootsville are provided by a JavaScript program, in the repository https://github.com/adventuring/tootsville.org.
In general, the following coding standards apply to the front-end:
The effects of this is that a typical Javascript source file will need to contain a series of declarations like this:
if (!('Tootsville' in window))
{ Tootsville = {}; }
if (!('Namespace' in Tootsville))
{ Tootsville.Namespace = {}; }
Tootsville.Namespace.funcName =
function (lambda, list)
{ ... };
Tootsville.Namespace.object =
{ foo: 42 };
Note, in particular, that we must not do something like:
Tootsville.Namespace =
{ funcName: function () { ... } };
This would potentially remove other objects in the Tootsville.Namespace namespace that may have been defined by other users.
The front-end's 3D support is courtesy of the Babylon.js library, which has its own on-line documentation.
The Gatekeeper object contains the bulk of the client's command processing. Functions in Gatekeeper are named -- i.e. the keys in the Gatekeeper hash table -- for the datagram from keys sent by the server. For example, Tootsville.Game.Gatekeeper.wtl is the handler for datagrams with from: "wtl" in their packet.
WRITEME
WRITEME
WRITEME